Just about every business, large or small, has a network these days. The benefits of linking a group of computers to share peripherals and some data are just too great to ignore. Even two- and three-person shops commonly have a network installedif for no other reason than to share a laser printer and a few documents. I'm often surprised at the number of home networks I see as well. It doesn't come as too much of a shock, though. Just think about the benefits to mom and dad of having a modern home workstation with a large hard drive, fast processor, and other new machine features. Using a peer-to-peer network allows the parents to give that old machine to the kids. Even if the kid's workstation only has a hard drive that's large enough for the Windows system files, their application files can reside on the larger hard drive of the machine used by their parents. Keeping the parents' machine separate from the kids' machine is a good way to keep your work separate from their play.
Regardless of the size of your network, there's bound to be some native support for it in Windows NT. You can even install limited support for some of those older peer-to-peer networks on the market, as long as they don't use real-mode drivers. Unfortunately, this leaves out older versions of LANtastic, as well as some of the other peer-to-peer offerings that worked well with Windows 3.x. On the other hand, the new Windows 95-specific offerings of these peer-to-peer networks seem to work fine with Windows NT. Of course, a few of these older networks don't provide the same level of features they did under Windows 3.x, but at least they work well enough to get the job done. Unless that old network provides some indispensable feature not provided by Windows NT, however, you'll probably want to get rid of it.
This chapter talks about the peer-to-peer networking capabilities Windows NT provides. For the most part, I purposely avoid talking about networks in general or even comparing the various options you have. The reason's simple: A single chapter can't possibly contain everything you'll need to ever know about networking. There are literally volumes of information about this topicand some people think that these are just barely adequate. We'll also look at the Windows NT networking architecture in this chaptersomething that's common to both of the networking models it supports.
Looking Ahead: This chapter doesn't contain everything you'll need to know about Windows NT networking. It looks at the low end of networking along: peer-to-peer network support. Chapter 22, "Client/Server Networking," looks at the client/server networking model supported by Windows NT. This is the kind of network that most medium to large businesses have installed. I've also devoted an entire chapter to security in this book; take a look at Chapter 23, "Security Issues," for details of this subject. Obviously, both these chapters look at the Windows NT view of things, with a spotlight on the user perspective.
What are some of the special features of this chapter? I'll provide you with some insights into the way Windows NT provides network servicesand that's something you'd be hard-pressed to find in one of those networking tomes. That's the whole reason for this chapter: to give you the Windows NT view of networking. I strongly suggest that you also spend some time learning about networks in general before you actually install one.
This chapter also assumes a certain level of knowledge on your part. I'm going to assume that you've already spent some time on a network and know some of the basics. You don't need to be a networking guru to understand this chapter, but you need to know what logging in is all about and some of the easier terms, such as network interface card (NIC). I've provided a complete list of all the harder terms and acronyms in Appendix C, "Glossary."
This section of the chapter looks at the how of network support under Windows NT. What can you expect, and why do things work the way they do? These are just some of the questions I'll answer here. Before we become too embroiled in some of the details of actually using Windows NT's network capabilities, I'd like to spend a little time looking at its architecture.
You need to understand a few things about Windows NT before you look at its architecture. The first thing you need to understand is that Windows NT has always been a peer-to-peer network. I'm talking from an architectural and usage point of view here (something called the network model), not the media point of view that often equates peer-to-peer to lack of power. Windows NT provides more than sufficient power to compete with many of the client/server model networks on the market. In fact, the server version of the product includes an advanced peer-to-peer network concept known as the domain. I'll talk about this concept in more detail later.
The second thing you need to understand is that Microsoft added the networking support for Windows NT to its I/O subsystem. In essence, the operating system views networking as extended I/O. This really makes sense when you think about it; a connection is still a connection, no matter how long the wire. Keep these two points in mind as you read the description of the architectural components. Figure 21.1 shows the Windows NT network architecture.
Figure 21.1. An overview of the Windows NT network architecture.
Some of the architectural components you should understand follow:
Note: You might wonder why Microsoft didn't combine the NP and the IFS Manager into one module. After all, from this discussion, it appears that the IFS Manager is simply part of an access strategy for network drives. Remember to take the whole picture into account. The IFS Manager also works with local drives. In addition, combining the modules would have produced a lot of replicated code. In essence, using two separate modules to access the drive status information and contents is the only way to get the level of flexibility network requests require with the minimum amount of code.
Tip: If you use both Windows NT and Windows 95, one of the first things you'll notice is that Windows 95 doesn't appear to use the same drivers as Windows NT does to get the network going. They do, in fact, use similar drivers and setups. Just replace the SYS extension on the first three drivers with a VxD, and you'll start to see the missing drivers on your Windows 95 machine. Windows 95 also uses a NETBEUI.VXD in place of NBF.SYSboth files serve the same purpose. I was surprised to see that both operating systems used the same name for the NIC driver.
This might seem like a lot of work just to create a workstation, but that's only half the picture on many peer-to-peer installations. Once you get past being a workstation, you have to take care of network requests as well. I'd like to show you how Windows NT provides peer-to-peer network services. The next section does just that. We'll look at Windows NT's peer-to-peer support from a server level. We'll also look at a lot of the implementation details. How do you share your printer or local hard drive with someone, for example?
Peer-to-peer networks represent the easiest and least expensive way to get started in networking. Everyone starts with a workstation, just like you would normally need in any business environment. You can't share resources on stand-alone workstations, however; you need to connect them in order to do that. In the past, the standard method for sharing resources was to buy additional machines (called servers) and place the common components there. The investment in hardware and software for a full-fledged network can run into tens of thousands of dollarsprohibitively expensive for many companies and out of reach for others. Peer-to-peer networks take a different route. One or more workstations also act as servers. In fact, if you work things right and the network is small enough, everyone will probably have access to everyone else's machine in some form. This means that, except for the NICs and cabling you'll need, a peer-to-peer solution under Windows NT is free for the asking.
Windows NT (both server and workstation version) provides peer-to-peer networking capabilities right out of the package. All you need to do is install a NIC on each machine, run some cable, and add a few drivers to your setup. In fact, the Setup program is designed in such a way that adding network support requires almost no effort at all on the part of the installer. Of course, after you get everyone set up, you'll want to install a few extra utilities, such as a centralized calendar and e-mail.
I was actually a little disappointed with the network utility feature set Microsoft decided to provide for Windows NT and Windows 95. Exchange is a wonderful e-mail system. Past versions of WFW came with Schedule+, however. Neither Windows NT nor Windows 95 provides this feature, and almost everyone will notice. Microsoft has introduced a Windows 95-specific version of Schedule+ as part of Office 95but it's incompatible in some ways with the old version of the product, and I wonder if it will be compatible with the new version for Windows NT. Even if the new versions of Schedule+ are compatible, you still have to deal with the incompatibility between the old and the new version of Schedule+. No matter which way you look at it, Schedule+ will become a thing of the past unless you're willing to perform a major upgrade of all your PCs at the same timesomething I doubt that most businesses could do even if they wanted to and had the required resources. I see a definite third-party opportunity here. People will still need a centralized calendar for planning meetings, and with Schedule+ gone, some third-party vendors will fill the gap.
Peter's Principle: Grabbing a Piece of the Past
You don't have to do without Schedule+ in your new Windows NT installation if you still have the files from your old version of WFW lying around. Even though that version of Schedule+ won't work with Exchange, you can still share information with other people on the network by copying the required files to your drive. Here are the files you should copy to your \WINNT folder:
*.CAL
DEMILAYR.DLL
MSCHED.DLL
MSMAIL.INI
MSREMIND.EXE
SCHDPLUS.EXE
SCHDPLUS.HLP
SCHDPLUS.INI
TRNSCHED.DLL
You'll also need to copy the following files to your \SYSTEM folder:
AB.DLL
FRAMEWRK.DLL
MAILMGR.DLL
MAILSPL.EXE
MSSFS.DLL
STORE.DLL
If the new version of Microsoft Mail doesn't exactly meet your specifications, you can still use the old version under Windows NT. Simply copy these files to your \WINNT folder:
MSMAIL.EXE
MSMAIL.HLP
MSMAIL.PRG
You will also need to copy VFORMS.DLL to your \SYSTEM folder.
After you copy all these files, make any required changes to the INI files. You'll want to change the directory names so that they match the new location, for example. The only problem I've detected with this arrangement so far is that Schedule+ won't remember your password. This is a small price to pay for using an old and familiar utility program.
Before we delve into all the details of how Windows NT supports peer-to-peer networking, let's take a brief look at the history of this networking system. The Microsoft end of peer-to-peer networking actually began with the introduction of DOS 3.1. Microsoft added the capability to lock files and records with that version of DOSa necessity for any kind of a network. In the same year (1984), Microsoft released a product called MS-NET. Just in case you've never heard of MS-NET (it wasn't all that popular), Microsoft turned it into LAN Manager.
Apple actually introduced the first successful peer-to-peer networking in a covert manner in 1985. They included AppleTalk in every Macintosh sold. Most people didn't realize they were actually using a network when they printed a document using the LaserWriter.
Peer-to-peer networking continued to be a cult classic in the years that followed. Many companies wouldn't recognize peer-to-peer networking as much more than a kludge or a poor man's network. Novell's NetWare used a client/server model that mimicked the big iron that corporations were used to using. It was comfortable using a network operating system that provided the look and feel of something substantial. In the PC world, many people thought it was client/server or nothing at all.
Note: Don't get me wrong. I'm not saying that peer-to-peer networking is the end-all solution for everyone. It's a very good solution for those on a limited networking budget who need to connect anywhere from two to 10 workstations. (I'm not talking about the domain server capabilities of Windows NT, which make a much larger number of connections possible; I'm talking about an actual peer-to-peer network setup in this case.) You might even want to look at it for workgroup connections (the very reason that Microsoft came out with Windows for Workgroups). You can combine the benefits of a client/server network with those of a peer-to-peer network under Windows NT. Although I would probably set an upper limit of 10 workstations for a peer-to-peer network, it might also work for larger numbers of workstations if the network load were very light. Of course, if you're willing to dedicate a machine to act as a server, you can get the same kind of capabilities with Windows NT as you can with other client/server model networks like NetWare, but that's not a peer-to-peer network in the strictest sense of the word.
A group of companies began distributing peer-to-peer networking solutions for the PC. One of the bigger contributors to this groundswell of alternative networking technology was Artisoft, which still sells LANtastic today. Other vendors contributed products such as 10Net and TOPS. The Software Link even marketed a processor-sharing operating system for the 80386 called PC-MOS/386. This solution and others allowed people to share system resources without having to purchase a file server to do it. In addition, the cost of a peer-to-peer network operating system was a lot lower because these vendors faced stiff competition from Novell.
I'm not sure whether Novell helped or hindered the expansion of peer-to-peer networking with its introduction of NetWare Lite in 1991. This product was designed not to interfere with Novell's client/server product. As a result, NetWare Lite wasn't well-designed or implemented. It couldn't even compete with other peer-to-peer products, such as LANtastic. The introduction of a peer-to-peer networking product by a major vendor such as Novell, however, at least put this type of networking on some people's agenda for the first time.
Things started to change for the better in the peer-to-peer market when Microsoft introduced Windows for Workgroups at the 1992 fall COMDEX trade show. This show of support by Microsoft legitimized the use of peer-to-peer networking for some corporate applications. Of course, Microsoft didn't go so far as to say that you could use it for more than a few people. Still, it was a step in the right direction.
So, has everyone bought into the peer-to-peer networking technology? Not by a long shot, and I doubt that peer-to-peer networking will ever take over the market. Using a solution such as Windows for Workgroups, Windows NT, or Windows 95 in the right place, however, could make a big difference for a very small cost. Both Windows NT and Windows 95 go a long way toward making dual solutionsa combination of client/server and peer-to-peer networkinga viable solution.
We've already taken a detailed look at what it takes to provide workstation support under Windows NT. What happens if you also want your machine to act as a server, though? Providing server support means that your machine must accept requests from other workstations, process those requests, and return the requested information. Figure 21.2 shows the Windows NT peer-to-peer network server support.
Figure 21.2. An overview of the Windows NT server architecture.
The following list describes each component in detail:
Tip: The security problems most people encounter with the Windows 95 PWL files are significantenough to garner major media coverage in the past few months. You can get around part of this security problem by removing user access to all the PWL files on your drive. If a user erases one of these files, it becomes a lot easier for him to override any security you provided. In addition, you can erase a user's PWL file to give him access to Windows 95 if he forgets his password. Of course, this means that you'll also have to perform the setup required to re-create that PWL file.
Understanding the server capabilities Windows NT provides is pretty straightforward from a conceptual point of view. Once you get past theory, however, implementation becomes another story altogether. The problem isn't due to a poor plan, but to all the compatibility issues that come into play. Fortunately for the user, the design of the server capabilities makes all these details fairly seamless.
I mentioned earlier that I would talk about the OSI model a bit to give you a better idea of how all the architectural details we just looked at fit into the grand scheme of things. I'll concentrate on the Windows NT model in this section, but I wanted to provide the NetWare and Internet models for discussion later.
Figure 21.3 The OSI model is the basis for some of the architectural details in Windows NT.
What I'd like to do first is describe the OSI model itself. No one actually follows this model verbatim, but it acts as a guideline for the various layers of communications required to enable a network to transfer data from point A to point B. (A layer is normally referred to by a variety of more specific names, such as protocol, but I want to keep things generic in this section.) I'm going to provide information about both the client and server side of the equation in the list. If you don't see a specific reference to either client or server, the text applies to both. The following list describes these default layers:
Now that you have a better idea of what the OSI model is, the question is how does Windows NT implement it? Various Windows NT elements often overlap one or more of the OSI layers. This tells you that the Windows NT elements actually accomplish one or more tasks. Notice that there are several paths through the Windows NT model. You can go from NetBIOS to NetBEUI to NDIS, for example. The one thing you should do about now is compare this figure with the description of Figure 21.1. You should start to see some similarities between the blocks on this figure and the levels of the OSI model. The MPR takes care of the environment subsystem level, which is the same as the presentation layer of the OSI model. I provided a pretty complete description of all these elements in that discussion, so I won't go through them again here.
What I didn't describe in the architectural section was the application layer. Windows NT provides three different methods for an application to start a network conversation. The first type is fairly obvious. Any time an application decides to open a file that isn't on the current machine, Windows NT has to perform some type of network file I/O.
Named pipes are something you'll never deal with directly, but something that advanced applications use quite a bit. One thread of execution can pass information directly to another thread using a named pipe. The great thing about named pipes is that the two threads don't have to be on the same machine. Think about that for a second and you'll realize that what I'm really talking about is a distributed application. Essentially, one machine is using another machine's processor and resources to get work done. Obviously, Windows NT places severe limitations on this right now, but it's important to realize that named pipes do exist.
What if you need to send a message to more than one thread? Suppose that you are looking for a particular piece of data in a database application. If you use named pipes, you have to tie up the network for a long period of time as you send messages from one server to the next looking for the data you need. Mailslots are the solution to that problem. A mailslot allows a thread to send the same message to more than one threadjust like you can with e-mail. You can also use mailslots in the opposite direction: to allow many threads to send a message to one thread. You might need to do this if a server is requesting the status of all workstations on the network through a network agent (a hidden application that monitors the status of a single machine), for example.
Domainit sounds more like a term of conquest than something associated with computer networks. The first thing you need to know is what a domain is. Think of a domain as a complex (or extended) form of workgroup. Essentially, a domain groups workstations and servers together into one unit. A domain allows you to access all the resources the domain provides (that you have the security rights to access) using a single login. Resources, in this case, include things like a system-wide security policy. A domain, then, is an all-encompassing version of the peer-to-peer network.
I want to take a very quick look at domains in this section. The first thing I'll do is tell you how they differ from workgroups, because Microsoft makes a distinctionone that's important enough for everyone to know. Second, I'll show you how the network looks at a domain versus a workgroup when it comes to configuration issues. You might not have a domain server available to you when you install your network. Joining a domain server later is relatively easy, but the dialog box for doing so is hidden in a place where some people won't easily find it.
There are two user-specific elements in addition to the things you normally associate with a workgroup that make up a domain. First, a domain uses a common resource database; Microsoft calls it a domain database. Users know what resources are available because the domain server can access the database to tell them. Second, a domain shares a common security policy. That's why you can access all the domain resources using a single password. The same security policy provides a consistent way for you to access resources on the system. It also determines what rights you have. From an administrator perspective, a domain also provides a common user list at all workstations. In other words, every workstation within a domain knows the rights and restrictions of all the users within the domain.
An administrator will see a lot of differences between a workgroup and a domain as well. The most important difference as far as I'm concerned is the fact that a domain provides better centralized user management and setup. One of the advantages to this control is the capability to add users to the domain from a remote location; I'll show you how this works in a few moments.
I wanted to make a distinction between a domain and a workgroup for a simple reason. The workstation version of Windows NT can't act as a domain server; you need the server version of the product to do that. If your network consists of a combination of Windows NT workstations (using the workstation version of the product) and perhaps a few Windows 95 workstations, you don't have a domain available to you. All you can create is a workgroup.
It's important to realize some of the limitations a workgroup has, but it's also important to know that these limitations might not even affect you. If you're running a five- or 10-person network, it's pretty unlikely that you'll be affected by the lack of centralized support in a workgroup setup. On the other hand, a network administrator who's responsible for 100 or more workstations would definitely notice the difference.
As a company adds new people to its staff, it usually needs to extend its network as well. After a long period of time, a network administrator will find that the workgroup configuration that worked fine with five people and adequately with 10 won't work very well at all with 20. Once you start getting to this level of complexity, you'll probably need to add a server.
I'm not going to spend time telling you about the relative advantages of a NetWare server over Windows NT (server version). That's a topic that a lot of people are trying to tackle and using a whole book to do so. This section assumes that, for whatever reason, you opted for the Windows NT Server.
After you have the server installed, you need to add people to it and reconfigure their workstations to recognize the server. In fact, what you need to do is join the new domain created by the Windows NT Server.
Tip: Windows 95 uses a different setup than Windows NT in this regard. You're joining a domain when you select User Level Access Control and then type the name of a Windows NT domain server on the Access Control page of the Network dialog box. You access this dialog box by right-clicking the Network Neighborhood icon.
Follow these steps:
Sharing is the main reason to install a network. The very concept of networks came from the need to share expensive peripheral devices and files. Windows NT provides an easy-to-use interface that allows you to share just about everything on your network with a few clicks of the mouse. Let's take a look at what you'll need to do to share files and other resources located on your machine.
The first thing I like to do before I start trying to share files is to make sure I actually have the required support loaded. This is a no-brainer under Windows NT because you really don't have a choice about loading the support during setup. Someone could come along and remove the support later, however, so it's always best to check. Just open the Network dialog box by right-clicking the Network Neighborhood icon and choosing Properties from the context menu. Select the Services page and look for a Server entry like the one shown in Figure 21.6.
Figure 21.6. The Server service allows you to share files and other resources under Windows NT.
Tip: The NCPA.CPL file in your \SYSTEM32 folder provides the actual interface you use to configure the network. Some older 16-bit Windows network installation programs insist on changing or adding a file named NETCPL.CPLthe name of the Control Panel extension under Windows 95 and Windows 3.x. If you ever lose your Network icon (as I once did), check to make sure that the NCPA.CPL file didn't get overwritten or otherwise corrupted. In fact, you might want to make a copy of this file before you install any real-mode network on your machine. Also check to make sure that you don't have a NETCPL.CPL file lurking in the \SYSTEM32 directory.
After you make sure that the Windows NT Server service is enabled, you need to select the items to share. Right-clicking any of your drive or printer icons and clicking Properties (depending on what support you installed) displays an additional Sharing page like the one shown in Figure 21.7. (The context menu also includes a Sharing option that will take you directly to this page.)
Figure 21.7. The Sharing page of the Print or Drive Properties dialog box lets you define the level and type of sharing for that device.
The first two radio buttons on this page allow you to determine whether the resource is shared. Selecting Not Shared means that no one can see the resource, even if they have other types of access to your machine. If you do select shared access, some additional blanks become available. The following paragraphs provide the details on how to manage a drive under Windows NT.
Note: Whenever you share a drive, Windows NT automatically creates a default share for administrative purposes. You'll want to leave this share alone and create a new share for your specific needs. Windows NT won't allow you to change any of the permissions with the default share or to modify it in any other way.
Peter's Principle: Maintaining Control of Your System
Sharing doesn't always mean that you allow everyone to access every resource on your machine. It's easier to simply provide access to an entire drive than it is to set the required level of security folder by folder, but the drive strategy might not be the best way to go when it comes to your company's health.
Many of us work with confidential information that we must keep safe, but we also work with other people who need to see some of the things we work with. Someone working in the accounting department might need to share analysis files with a workgroup, for example. However, can you imagine what would happen if he also shared access to the payroll files? What about the new plans that your company might be working on? Even though you need to share access to the current project, you'll want to keep that new project a secret. A little bit of discretion can save you a lot of headaches later.
It's important that you provide the right level of access to everyone in your workgroup. I won't cover every bit of security in this chapter (we'll look at this in detail in Chapter 23), but you might want to put your thinking cap on now. Where are the potential security leaks in your company? It's a well-known fact that people complain when they don't have enough access to the network. Have you ever heard anyone complain about having too much access?
Finding the areas where people have too much access will give you the most trouble. Audits and other forms of security checking are just as important as the sharing itself on your network. Performing an audit takes time and resources that might be very difficult to defend using when management asks for an accounting. Of course, having a security breach is even more difficult to defend. Allow others to use the resources you have available, but don't allow misuse of those resources. It's up to you to do your part in maintaining the proper level of security on your network.
Unlike Windows 95, you can create more than one share name for a particular resource under Windows NT. Each share name can have more than one group associated with it and a variety of restrictions for that group. To create a new share, simply click the New Share button. You'll see the New Share dialog box shown in Figure 21.8.
Figure 21.8. The New Share dialog box allows you define how you plan to share a drive or printer with other people.
Tip: Windows NT doesn't limit you to providing access to an entire drive or printer. You can define access to an individual directory as well. I find it very convenient to set aside a temporary directory on my machine for file sharing. People can upload their files to a specific directory and avoid changing the contents of the rest of my drive. You can use the same principle for other resources. The key is to maintain control of your system.
You'll need to provide a resource name in the Share Name field. This is how Windows NT will present the resource in dialog boxes, such as with the Drives field of the File Open dialog box. The optional Comment field allows you to provide a little more information to someone who wants to share the resource. I normally include the precise resource name and my name as part of the comment. This reduces the chance that someone will accidentally try to use a resource on my system.
After you define a resource name and assign it a comment, click the Permissions button to display the dialog box shown in Figure 21.9. The first field, Access Through Share, tells you the shared named for the resource. The Owner field tells who owns the resource. In most cases, you won't see a name here unless someone has set the ownership setting.
Figure 21.9. The Access Through Share Permissions dialog box shows which user group or single user is allowed to access a drive or printer.
The third field contains a list of users and groups that can access the resource. If you try to change this field directly, however, you'll find that you can't. Click the Add button to add a new user or group; you'll see the dialog box shown in Figure 21.10. Normally, this dialog box doesn't show a list of users. Just click the Show Users button to display a list of users if you want to assign individual access. If you want to see who belongs to a particular group, highlight the group name and click the Members button. The Search button allows you to find a particular user or group.
Figure 21.10. The Add Users and Groups dialog box allows you to define who will be able to access a particular resource.
The Add Names listbox shows all the new users or groups that you want to give access to. It won't show any existing user or group access. To add a user or group to this field, highlight their name in the Names listbox and then click the Add button.
Use the Type of Access drop-down listbox to define the level of access to a particular resource. You can provide four actual levels of access: no access, read access, change access, and full access. Windows NT defaults to read access, which allows someone to read from a resource but not modify it in any way. Change access allows someone to read and write to a resource but not to create or delete anything. This allows you to set up a group of shared files where the users can edit a file but not delete it. Obviously, full access allows the user or group to do anything you can with the resource. Use this option with discretion because someone can damage your drive or other resource if you give them full access.
Note: Some products, such as Microsoft Word (and most other word processors), require full access to a drive in order to work. That's because they create a backup file before writing any changes to the original word processing file. You might have to limit word processing files to one or two directories. That way, you can still limit overall drive access and provide better security. We'll cover security issues in more detail in Chapter 23.
After you select all the people you want to give a particular level of access, click OK. You'll see the new users and groups added to the Name box of the Access Through Share Permissions dialog box. At this point, you might wonder how to add password protection to your resource. Users will have to log onto your system before they can use a resource. That password acts as their key to gaining access to the resource, so Windows NT doesn't assign any added password to the resource here. In Chapter 23, I'll show you some techniques for adding more security to your system. To complete the action, click OK in the Access Through Share Permissions dialog box and then click OK in the Drive Properties dialog box.
A single resource can have more than one share name. You might need to remove one of those share names when a particular user or group no longer needs it. To remove a shared resource name, open the Sharing page of the Drive Properties dialog box (refer to Figure 21.7). Select the shared resource name you want to remove from the Share Name drop-down listbox. Make sure that it's the one you actually want to remove, because Windows NT won't provide much feedback in the way of an Are You Sure confirmation box. Click the Remove Share button, and all the permissions associated with a particular shared name will be marked for deletion. At this point, you can still recover them by clicking Cancel. If you click OK, the change becomes permanent.
You'll eventually need to modify some details associated with a shared resource. If a user leaves the company, for example, you'll need to remove his access to your machine. To start the process, open the Sharing page of the Drive Properties dialog box. Select the name of the shared resource you want to change from the Shared Name drop-down listbox. Click Permissions to display the Access Through Share Permissions dialog box (refer to Figure 21.9).
Removing a share is pretty simple. Just highlight the share you want to remove and then click the Remove button. I wish, in some respects, that Microsoft had made this a little more difficult or at least provided some additional feedback. Right now, you won't get any kind of feedback at all except for a missing line in the Name box. With this in mind, I always double check a share before I remove it.
Changing a share is pretty easy, too. Just select the user or group you want to change, and then select a new level of access from the Type of Access drop-down listbox. I described these various access levels in the "Creating a New Share" section, so I won't do it again here.
Click OK to exit the Access Through Share Permissions dialog box. You can still change your mind at this point by clicking the Cancel button in the Drive Properties dialog box. If you decide to make the change permanent, just click OK.
Windows NT provides a fairly complex and complete set of Transmission Control Protocol/Internet Protocol- (TCP/IP) related features. Think of a protocol as a set of rules for a game. The rules tell you how to play the game and give you a basis for playing it with someone else. A protocol performs the same task on a network. It establishes rules that allow two nodesworkstations, mainframes, minicomputers, or other network elements like a printerto talk to each other. TCP/IP is one of the more popular sets of network communications rules.
Windows NT also provides support for Point-to-Point Protocol (PPP). Just like TCP/IP, PPP is a set of communications rules. In this case, however, the rules provide a method for conducting on-line (from one point to another) communications. Both these features allow you to connect to a UNIX host or the Internet, or to enhance your Dial-Up Networking capability.
Tip: You might find that you don't need the full TCP/IP service package. Windows NT also provides a service-oriented TCP/IP package called Simple TCP/IP. You can install it using the same procedure I describe in the "SNMP Support" section that follows. In fact, Figure 21.14 shows the Simple TCP/IP service listed right above the SNMP service.
In almost all cases, the support Windows NT provides deals with remote communications, but there are exceptions. The monitoring capability provided by SNMP, for example, could work in a local server setup. It's important to include this support as part of the operating system for two reasons. First, adding TCP/IP and PPP to the operating system makes it easier for software developers to write agents (special drivers or applications that use the rules these protocols establish to perform useful work). If you added either protocol as a third-party product, there wouldn't be any standardization, making it nearly impossible for other third-party vendors to write standard agents. Second, adding this level of protocol support to the operating system means that Microsoft can incorporate an additional level of support as part of its utility program offerings. You'll find that both protocols are important when it comes to communicating with the Internet through Microsoft Network (MSN), for example. Before you can use TCP/IP, you have to install it.
Tip: Installing TCP/IP support before you install Dial-Up Networking will save you some extra steps later. The Dial-Up Networking installation routine automatically installs the required protocols for you if you install TCP/IP support first.
Let's quickly go through a few of the things you'll need to do to install TCP/IP support:
Note: If you have RAS installed, Windows NT asks you whether you want to configure it to use TCP/IP. Other TCP/IP-capable services also require configuration. Windows NT will probably ask you about each one it encounters. Simply click the Yes button when asked and complete the configuration process. Windows NT then proceeds with the rest of the TCP/IP installation.
Configuring the TCP/IP support after you get it installed is easy. All you need to do is select the TCP/IP entry on the Protocols page of the Network Properties dialog box and click the Configure button. You'll see a dialog box similar to the one shown in Figure 21.13. (I discussed the various TCP/IP setup options in Chapter 4, "Setup Primer.") Essentially, all the pages in this dialog box allow you to set the addresses and other TCP/IP properties for your machine. All the setup options available for automatic setup are present when you use this manual technique.
Figure 21.13. You can use the TCP/IP Properties dialog box to configure TCP/IP support under Windows NT.
After you complete this initial installation process, you need to perform other installations to provide specific levels of support. You need to install Dial-Up Networking, for example, and then the TCP/IP support that Windows provides before you can access that support for a remote connection. I already talked about the communications end of this support in Chapter 17, "Windows NT Connections," and Chapter 18, "Talking to the Outside World." The following sections show you how to configure Windows NT to use both TCP/IP and PPP from a networking perspective. I'll also cover a few of the usage issues you need to know about.
Windows NT provides remote monitoring agent support for agents that use the Simple Network Management Protocol (SNMP). SNMP was originally designed for the Internet. It allows an application to remotely manage devices from a variety of vendors, even if that device doesn't normally work with the managing device. A mainframe can use SNMP to send updated sales statistics to a group of satellite offices in a large company, for example. You can use an SNMP console to monitor a Windows NT workstation once this support is installed. SNMP support under Windows NT conforms to the version 1 specification. Microsoft implements SNMP support for both TCP/IP and IPX/SPX using WinSock (which I'll describe later).
The following procedure allows you to install SNMP support under Windows NT:
Figure 21.16. The Microsoft SNMP Properties dialog box allows you to configure SNMP for useyou're looking at the Agent page here.
I'll have to stop the procedure here a few moments to explain the entries in this dialog box. As you can see from the figure, three pages of configuration data are associated with this dialog box. The following list talks about the items on the first page:
On to the second page of our configuration: Traps. Figure 21.17 shows what this page looks like. So what precisely is a trap? A few of you programmers should have a good ideaespecially if you've spent time writing BASIC applications. What happens on a remote communication if someone wants to access a community (the hosts that your computer can connect to) that doesn't exist? Let me put this in easier-to-understand terms. Suppose that you want to open a file, so you select the File | Open command. Now, instead of typing a name of a file that exists, you either leave the file name blank or type the name of a file that doesn't appear on the drive. In a program, this produces an error condition. You'll see a message from Windows or the application saying that the file doesn't exist; some well-rounded applications will even give you a chance to create a new file with that name to get around the error condition. In SNMP terms, a trap is something that looks for errors and then produces a message to deal with it. The process is a bit more complex than that, but this is a good starting point. There's also a certain amount of security involved here as well. If someone is requesting the name of a community that doesn't exist, you can assume one of two things: He either made a mistake or he's a hacker trying to break into your system. The trap has to be able to deal with both conditions.
Figure 21.17. The Traps page of the Microsoft SNMP Properties dialog box allows you to deal with error conditions and security to a certain extent.
Tip: You're going to look at a lot of definitions for traps in a variety of books. Here's my short definitionthe least complex way of looking at this complex topic. A trap is an automatic monitoring method. It automatically updates the host when specific events occur on your machine.
Now that we're all talking about the same thing, let's take a look at the list of fields in this dialog box:
If you've looked at just about any trade press paper lately, you'll know that security is a major issue. The next page in the Microsoft SNMP Properties dialog box should come as no surprise then (see Figure 21.18). It allows you to change the security for your SNMP configuration. More than that, it provides the means for creating connections to your computercertainly a part of the security process.
Figure 21.18. The Security page of the Microsoft SNMP Properties dialog box is one that you can't afford to ignore if network security is important to you.
The following list provides a description of each of the fields in this dialog box:
I'll bet by this point, you've forgotten that we were in the middle of an installation procedure. The only thing you need to do now is click the OK button in the Microsoft SNMP Properties dialog box to complete the process. Once you do, you'll be back at the Network Properties dialog box. Just click OK to close this dialog box as well.
Using the Internet requires some form of browser support if you want to download files or upload messages. FTP is actually a utility program that Windows NT installs for you along with TCP/IP support. It's a DOS application that uses a standard character-mode interface. The syntax for FTP follows:
FTP [-V] [-N] [-I] [-D] [-G] [<Host>] [-S:<Filename>]
Tip: Once you get more familiar with the Internet, you'll find that the FTP and Telnet utilities provided with Windows NT are pretty limited as far as browsers go. Some of the page links didn't work properly, for example, and I didn't see the same level of graphics that Netscape and Mosaic provide. A lot of other browserssuch as Netscape, Mosaic, Gopher, Archie, and WAISwill make your life a lot easier. You can get any of them commercially or as shareware from Internet servers. You can also get the World Wide Web (WWW) browser from a variety of sources. A few on-line services like CompuServe make special versions of these browsers available to you. CompuServe uses the Spry Mosaic browser with its CompuServe Information Manager, for example, to make access to both services seamless. I also tell you about the new Internet Explorer provided with Windows NT in Chapter 18. The bottom line is that you need an easy-to-use browser that meets your particular needs to make the best use of the resources the Internet makes available.
The following list defines each FTP option:
The FTP utility provides a surprising array of commands you can use once you run it. There really are too many to list here, but you can get a list easily enough. All you need to remember is one command: the question mark (?). If you type a question mark, you will see a list of all the things you can do with FTP.
Windows NT provides both Serial Line Internet Protocol (SLIP) and Compressed Serial Line Internet Protocol (CSLIP) support for remote network connections as a client. It doesn't provide this support as a server. This is the type of connection supported by older UNIX remote servers.
Fortunately, you don't have to do much in the way of installation to get SLIP and CSLIP support if you've already configured Windows NT for remote communications. There are only two steps: Install RAS support using the procedure in Chapter 17, and then install TCP/IP support using the procedure in this chapter. After you accomplish these two steps, you'll have to open the Remote Access application.
I've covered all the procedures for creating utilities in this program in Chapter 17. What you'll need to do is create a new connection. I talked about the Add Phone Book Entry dialog box shown in Figure 21.19 before. There is one major difference, though, for a SLIP connection.
Figure 21.19. The Add Phone Book dialog box allows you to add new connections to the Remote Access utility.
Click the Network button in this dialog box, and you'll see the Network Protocol Settings dialog box shown in Figure 21.20. Normally, Remote Access selects the PPP radio button in this dialog box. I've selected the SLIP entry in this case. That's the only extra step you need to take to create a SLIP connection. You'll probably want to keep all the other settings the same. The exception is if you want to create a CSLIP connection; you'll have to enable the Force Header Compression checkbox.
Figure 21.20. The Network Protocol Settings dialog box allows you to create a SLIP or CSLIP connection.
The Telnet is another browser utility program that Windows NT installs automatically when you install TCP/IP support. The strange thing is that Windows NT doesn't automatically install it in your Start menu. You'll need to add it manually. The Telnet utility always appears in your \SYSTEM32 folder.
When you open the Telnet utility, you see a dialog box similar to the one shown in Figure 21.21. It's fairly simple to operate this application. The four menus provide a very basic set of features for logging onto a host and keeping track of your session.
Figure 21.21. Telnet provides a very basic terminal-like front end for a host connection.
Choosing the Connect | Remote System command displays the Connect dialog box shown in Figure 21.22. This dialog box has three drop-down listboxes. The first contains the name or address of the host you want to connect to. The second field contains the host type. The third field specifies a terminal type. In most cases, you won't have much of a choice about terminal types, but I find the ANSI terminal is usually a bit easier to use if you can gain access to a host that supports it. Disconnecting from the host is very easy. Just choose the Connect | Disconnect command.
Figure 21.22. You use the Connect dialog box to tell Telnet how and where to make a connection.
The Edit menu contains the normal Copy and Paste commands, so I won't spend any time discussing it here. The Terminal menu provides a few options you should know about. You can use the Start Logging and Stop Logging options to keep track of your session, for example. The Start Logging option displays a File Open dialog box that you can use to find or create a log file.
Figure 21.23 shows the dialog box that appears after you choose the Terminal | Preferences command. The Terminal Options and Emulation groups are pretty self-explanatory. They configure the way the host machine interacts with the terminal emulation program. The Fonts button allows you to select a different font than the default Fixedsys. You can also add a little color to the display by clicking the Background Color button. I normally keep it set as is because you can't change the foreground color. The Buffer Size field allows you to change the number of lines of text you'll see in the terminal window. Telnet uses a default setting of 25, which seems to work well with most hosts.
Figure 21.23. Use the Terminal Preferences dialog box to configure Telnet to the host you plan to connect with.
Have you ever wondered how you can figure out which computers on the network require new hardware before you can make an upgrade? Will your current hardware run Windows NT, for example? You might ask just that question in the next few months after you've had time to evaluate Windows NT. Desktop Management Interface (DMI) is part of System Management Server. It's the hardware-auditing component of this utility.
A vendor will write a management information file (MIF) that contains all the particulars about a piece of equipment. When the System Management Server looks at a workstation and finds this file, it adds its contents to a SQL database that you can open with any number of products. In addition to the hardware information, System Management Server adds the software-auditing information that it finds to the database. The combined software and hardware information will give you the data required to know whether a particular workstation can run a piece of software without an upgrade.
Unfortunate as it might seem, none of this is fully implemented in the workstation version of Windows NT as of this writing. DMI support is present, but you won't find System Management Server anywhere on your CD-ROM. This is a future upgrade that Microsoft might make to Windows NT. Although it might not help you much right this second, it's good to know that help is on the way. If you have the following equipment, however, you can implement System Management Server today:
Remember near the beginning of this chapter when we talked about network transports and the way Microsoft implements them? I mentioned then just how complex a network transport could get if you added a few features. Remote procedure calls (RPCs) are a somewhat new concept for Windows NT; Microsoft added them in the last version of the product. They're implemented as a network transport mechanism using named pipes, NetBIOS, or WinSock to create a connection between a client and a server. RPC is compatible with the Open Software Foundation (OSF) Data Communication Exchange (DCE) specification.
So what does RPC do for you? OLE uses it, for one. Actually, OLE uses a subset of RPC called light RPC (LRPC) to allow you to make connections that you couldn't normally make. We discussed this whole issue in detail in Chapter 12, "DDE and OLE," so I won't talk about it again here. OLE is only the tip of the iceberg, however. There are other ways in which RPC can help you as a user.
Think about it this way: You're using an application that requires any number of resources in the form of DLLs, VxDs, and other forms of executable code. Right now, all that code has to appear on your machine or in a place where Windows will be certain to find it. This means that every time a network administrator wants to update software, he has to search every machine on the network to make sure the job gets done completely. What if you could "borrow" the DLL from someone else's machine? That's what RPCs are all about. An RPC lets your application grab what it needs in the form of executable code from wherever it happens to be.
Windows sockets (WinSock) started out as an effort by a group of vendors to make sense out of the conglomeration of TCP/IP protocol-based socket interfaces. Various vendors had originally ported their implementation of this protocol to Windows. The result was that nothing worked with anything else. The socket interface was originally implemented as a networked interprocess communication mechanism for version 4.2 of the Berkeley UNIX system. Windows NT requires all non-NetBIOS applications to use WinSock if they need to access any TCP/IP services. Vendors may optionally write IPX/SPX applications to this standard as well. Microsoft includes two WinSock applications with Windows NT: SNMP and FTP.
Before I go much further, let me quickly define a couple of terms used in the last paragraph. We looked at what a protocol was earlier. It's a set of rules. TCP/IP is one common implementation of a set of rules. Think of a socket as you would the tube holder found in old televisions and radios. An application can plug a request (a tube) for some type of service into a socket and send it to a host of some kind. That host could be a file server, a minicomputer, a mainframe, or even another PC. An application can also use a socket to query a database server. It can ask for last year's sales statistics, for example. If every host uses a different-sized socket, every application will require a different set of tubes to fit those sockets. WinSock gets rid of this problem by standardizing the socket used to request services and make queries.
Besides making the interface easier to use, WinSock provides another advantage. Normally, an application has to add a NetBIOS header to every packet that leaves the workstation. The workstation at the other end doesn't really need the header, but it's there anyway. This additional processing overhead reduces network efficiency. Using WinSock eliminates the need for the header, and the user sees better performance as a result.
Sockets are an age-old principle (at least in the computer world), but they are far from out of date. The WinSock project proved so successful that Microsoft began to move it to other transports. Windows NT includes a WinSock module for both the IPX/SPX and NetBEUI transports, for example.
Of course, WinSock is really a stopgap measure for today. In the long term, companies will want to move from the client/server model for some applications and use a distributed approach. This will require the use of an RPC interface instead of WinSock. We've already looked at the implications of RPC in this chapter.
So what does it take to implement WinSock on your system? A group of five files in your \SYSTEM32 and \SYSTEM32\DRIVERS folder is used to implement WinSock. The following list tells you what they are and what tasks they perform:
Use the information in this chapter to determine which of your system resources are shared and which are not. You might want to create a written list of who has access and where for future reference. This allows you to plug any security leaks whenever someone leaves the company.
After you determine who has access to your machine, look for any security leaks. Make sure that you change passwords on a regular basisespecially after someone leaves the company. Check to see how the use of your system resources by others affects system performance and overall usability.
We discussed the network subsystem architecture in this chapter. Go through your \SYSTEM32 folder and see whether you can identify the components that comprise it. See whether your network needs any specialty components because it uses a different protocol than normal. You might also want to take this opportunity to look for any real-mode drivers that are still lurking around your hard drive.